This invention relates generally to the communication of digital data in digital data networks and more specifically to communication of digital data in wireless, mobile-access, Internet protocol-based data networks. This invention is particularly relevant to handoff operations performed by mobile nodes roaming in wireless, mobile-access, Internet protocol-based data networks.
Throughout evolution of wireless communications systems, technical challenges associated with implementing wireless communication have always been posed by a mobile node (MN), as traveling from one area to another, irregularly changing its point of attachment to terrestrial radio access point (AP) with which it is communicating wirelessly. Indeed, the most critical factor in achieving good performance for mobility protocols is the design of handoff. A handoff occurs when a MN moves from one radio AP to another. A mere change of radio AP is called a xe2x80x9cLayer 2 (L2) handoff,xe2x80x9d which does not involve any Layer 3 (L3) signaling at the IP level. If the new radio access point is associated with a new subnet, i.e., if the MN moves from one subnet to another, a changing in routing reachability occurs and requires Layer 3 (L3) protocol action. This L3 protocol action is called a xe2x80x9cL3 handoffxe2x80x9d and usually involves exchange of a series of IP messages that are used to update routing information for the MN to make sure that data destined to the MN is routed through the new subnet to the MN.
The Internet Engineering Task Force (IETF) has proposed several standards to deal with the handoff operations. For instance, IETF RFC 2002 titled xe2x80x9cIP Mobility Support,xe2x80x9d which is usually referred to as Mobile IP Version 4 (IPv4), and draft working document  less than draft-ietf-mobileip-ipv6-17 greater than  entitled xe2x80x9cMobility Support in IPv6,xe2x80x9d also referred to as Mobile IP Version 6, both of which are incorporated herein by reference, describe how a MN can perform L3 handoffs between subnets served by different agents. Under Mobile IPv4, a MN is given a long-term home address by its home agent (HA) and uses the home address as the source address of all IP data that it sends. When located on a foreign subnet away from its home subnet, a xe2x80x9ccare-of addressxe2x80x9d (CoA) is associated with the MN and reflects the MN""s current point of attachment. Through an L3 handoff, the CoA is registered in the MN""s home agent to enable the HA to update its binding or data-routing information for the MN. A similar protocol is implemented under Mobile IPv6.
The L3 handoff process pursuant to RFC 2002 requires mobility agents, i.e., foreign agents and home agents, to advertise their presence via Agent Advertisement messages. A MN that receives these Agent Advertisements determines whether it is operating on its home subnet or a foreign subnet. When the MN detects that it has entered a new subnet, it obtains a CoA from Agents Advertisements sent from the foreign agent serving the foreign network. The MN then registers the new CoA by sending a registration request including the CoA to its home agent (HA). The L3 handoff completes when the HA receiving the registration request updates its internal binding information for the MN and returns a registration reply to the MN. After the registration, data sent to the MN""s home address are intercepted by the HA, tunneled by the same to the MN""s CoA, received at the tunnel endpoint (either at a FA or at the MN itself), and finally delivered to the MN. In the reverse direction, data sent by the MN is generally delivered to its destination using standard IP routing mechanisms, not necessarily passing through the HA.
Mobile IP was originally designed without any assumptions about the underlying link layers over which it would operate so that it could have the widest possible applicability. This approach has the advantage of facilitating a clean separation between L2 and L3 of the protocol stack, but it has negative consequences. Because of the strict separation between L2 and L3, a MN may only communicate with a directly connected FA. This implies that a MN may not begin the registration process until it obtains L2 connectivity to a new FA after having lost L2 connectivity to the old or previous FA. In addition, the registration process itself takes some time to complete as the registration request and reply messages propagate through networks between the MN to its HA. The time from the last L3 connectivity between the MN and the old FA, to the time when the L3 connectivity to a new FA has been established manifests itself as handoff latency. During this time period, the MN is not able to send or receive any data. The handoff latency resulting from standard Mobile IP handoff procedures could be greater than what is acceptable to support real-time or delay sensitive traffic.
Several protocol designs have been proposed for both Mobile IPv4 and IPv6 that seek to reduce the amount of handoff latency. For instance, Internet Draft xe2x80x9cLow Latency Handoffs in Mobile IPv4xe2x80x9d  less than  draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt greater than , which is incorporated herein by reference, proposes two techniques for minimizing the period of time when a MN is unable to send or receive data due to the delay in the Mobile IP registration process. One such technique is xe2x80x9cpre-registration handoffxe2x80x9d which allows the MN to communicate with a new FA while still connected to the old FA. The other is called xe2x80x9cpost-registration handoffxe2x80x9d which provides for data delivery to the MN at the new FA even before the formal registration process has completed. More specifically, under the pre-registration handoff method, the old FA, initiated by an L2 trigger, notifies the MN of a new FA. The MN then begins an L3 handoff with the new FA while still in communication with the old FA, i.e., while receiving and sending data through the old FA. In other words, the pre-registration handoff method allows the L3 handoff to begin even before the L2 handoff begins and thus helps achieve seamless handoffs between old and new FAs. The new FA may initiate the pre-registration handoff by sending its presence through the old FA to the MN. Also, the MN may become an initiator of the pre-registration handoff by sending a Proxy Router Solicitation to the old FA, which in return advises the MN of the new FA. In any event, a prompt and timely L2 trigger is necessary to implement the pre-registration handoff.
The post-registration handoff method allows the old FA and new FA to utilize L2 triggers to set up a bi-directional tunnel (BDT) between the old FA and new FA that allows the MN to continue using the old FA while on the new FA""s subnet. The post-registration handoff is likewise initiated by an L2 trigger that is provided to either the old FA or the new FA. Following a successful Mobile IP Registration between the MN and the old FA, the old FA becomes the mobility anchor point for the MN. Either the old FA or the new FA then receives an L2 trigger informing that the MN is about to move from the old FA to the new FA. The FA (old or new FA) receiving the trigger sends a Handoff Request to the other FA (new or old FA), which returns a Handoff Reply, thereby creating a bi-directional tunnel between the FAs. When the link between old FA and MN is disconnected, the old FA begins forwarding MN-bound data through the tunnel to the new FA. When a new link is established between new FA and MN, the new FA begins delivering the data tunneled from the old FA to the MN and forwards any data from the MN through the reverse tunnel to the old FA. After the L2 handoff is completed, the MN may, while sending and receiving data through the tunnel from the new FA, perform a formal Mobile IP registration with the new FA. The initiation of this formal registration may be delayed. Thus, the post-registration handoff enables a rapid establishment of service at the new FA.
Internet Draft xe2x80x9cFast Handovers for Mobile Ipv6xe2x80x9d  less than draft-ietf-mobileip-fast-mipv6-03.txt greater than , which is incorporated herein by reference, proposes similar techniques for minimizing the handoff latency for Mobile Ipv6.
However, both pre and post-registration handoff methods build upon some critical assumptions. For instance, it is assumed in both methods that L2 triggers are properly fired well in advance to notify an upcoming change in the L2 point of attachment of the MN. In the real world, it cannot be expected that such L2 triggers are always properly fired well in advance. For instance, certain access technologies just do not support advance L2 triggering. Examples of such access technologies are IEEE 802.11 and Bluetooth.
Another assumption on which both pre and post-registration methods rely is that a target node is always identifiable well in advance of an L2 handoff. For example, it is well known to use beacon signal strength from nearby nodes for detecting reachability of the nearby nodes. But it is not a viable assumption that nearby nodes broadcast the same pilot beacon signal at the same strength level. In situations where heterogeneous networks coexist that support different access technologies, different beacon signals are broadcasted at various strength levels. Beacon signals from different access technologies are simply incomparable to determine one over another. After all, if a mobile node is surrounded by heterogeneous networks that support different access technologies, identification of a target node is impossible until the mobile node actually enters the subnet served by the target node.
Besides, there should be more than one motivation for firing an L2 trigger to notify an imminent L2 handoff. Anticipation of losing L2 connection with the currently connected network is not the only one motivation for L2 triggering. Timing of firing such an L2 trigger should differ, depending on the motivation behind it. The proposed pre and post-handoff protocols are simply not designed to handle difference in timing of such an L2 trigger.
The present invention provides a tunneling handoff process that can minimize the handoff latency associated with the standard Mobile IP registration. One of the ways to minimize the handoff latency is to begin the preparation for a handoff process as early as possible, even before a target node is identified. In the present invention, when nearby nodes are detected, these detected nodes are identified as candidate nodes. Detection of the existence of nearby nodes should be possible even in the situation where these nearby nodes use different access technologies. For instance, pilot beacon signals may be considered advertisements of the presence of candidate nodes although it may not be possible to compare them qualitatively and quantitatively if the beacon signals emanate from different access technologies.
In the present invention, as soon as candidate nodes are identified, tunnels are established between the source node and the candidate nodes. The tunnels are used to forward data to the mobile node after a communication link between the mobile node and the source node goes down. As soon as the mobile node enters one of the nearby networks and identifies a target node, the tunnels are torn down except the tunnel for the target node.
More specifically, in the present invention, at least one of the mobile node and the source and target nodes is triggered to initiate the handoff process according to the present invention. Upon triggered, at least one candidate node is identified to the source node. A tunnel is established between the source node and each of the at least one candidate node. Then, one target node is identified from the at least one candidate node. Thereafter, the tunnels are removed except the tunnel for the one target node. Using the tunnel for the one target node, the mobile node keeps data communication with the source node through the one target node after the mobile node completes an L2 handoff from the source node to the one target node but before undergoing IP routing update with the one target node.
The mobile node may be triggered to initiate the handoff process according to the present invention or may self-trigger itself to initiate the handoff process according to the present invention when it detects the presence of at least one candidate node. Signals broadcasted from nearby nodes may be used to detect the existence of the nearby nodes. The signals broadcasted from the nearby nodes may be L2 pilot beacon signals.
A link up between the mobile node and the one target node is used as a trigger to determine the identity of the one target node. Once the one target node is identified, the mobile node may notify it to the source node. Alternatively, the one target node may identify itself to the source node.
A link down with the mobile node may be used as a trigger for the source node to begin forwarding data to one or more of the at least one candidate node. If the link down with the mobile node occurs after the tunnels are established but before one target node is identified, the source node begins forwarding data to all the at least one candidate node. If the link down with the mobile node occurs after one target node is identified, the source node begins forwarding data to the one target node, instead of forwarding data to all the candidate nodes. If the link down with the mobile node occurs after the tunnels are established but before one target node is identified, the source node buffers data to be forwarded to the mobile node until after one target node is identified, and it begins forwarding the buffered data and subsequent data to the one target.